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ABSTRACT 



A method and ^aratus is provided to accomplish creation 
and serving of data objects among various conmumication 
protocols. The method and apparatus can be used in such 
applications as an on-line classified advertising system on 
the Internet involving the World Wide Web and electronic 
mail In the apparatus, a request decoder receives an incom- 
ing request, decodes the request using configurations from a 
configuration database in order to identify which protocol 
was used to transmit the request, and generates ^m the 
request a corresponding abstract data object A data proces- 
sor merges data from a main database with the abstract data 
object. An object f conatter fonnats the abstract data object 
including the merged data. An object ddivaa formats the 
object for outgoing transmission according to a protocol of 
an intended recq>ient The functions of object deliverer may 
be performed by the object formatter. 

31 Claims, 11 Drawing Sheets 
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From: anneQwhatsamatta-u.edu 
To: seiverOfbobar.oom 

Please send me my tavorite table of figures 



Incoming Request for Object 



FIG.2A 
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HeUo. [mofge USER NAME]. <P> 
[If [capabOtty TABLES] 

{<CENTER>Here is the table you 

reque8ted:<P> 

rindude THE_TABLE]<CENTER>} 
{I am aorry, but your dient 
doeant support tables.}] <P> 
rindude THE FOOTER] 



Abstract DFL-Embedded DPL Object 
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Hello. Anne. <P> 

<CENTER>Here 18 the table you 
rBquested:<P> 

<TR><THXTH><TH>X<TH><TH>Y</TH></TR> 
<TR><TH>A<rH><TD>X<rD><TD>Y</TD></TR> 
<TR><TH>B<TH><TD>X<m)><TD>Yv/TD></TR> 
<n'ABLE><;«:ENTER> <P> 

<B>Copyright 1995 Foobar Corp. </B> 



Unfbmnatted OFL Object (Processed) 
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HeJIo, Anne. 

Hafe is the table you requested: 

I X I Y I 
+— — ^ 



A I 1 I 2 I 

^. — + ^ + 



B I 3 I 4 I 
COPYRIGHT 1995 FOOBAR CORP. 



Concrete Object (Client-Specific) 



FIG. 2D 
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From: servwOfoolMir.oom 
To: armoOMrhat8afnatta-u.edu 

Hello, Anne. 

Here is the table you requested: 

I X I Y I 
+ f + 



A I 1 I 2 I 
+ + 



B I 3 I 4 I 
+ + + 

COPYRIGHT 1995 FOOBAR CORP. 



Outgoing Otaject 



FIG.2E 
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Configuration 
Rule Sets 




Abstract 

Objects 

for 

Delivery 



Request Decoding 



FIG. 4 
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INTEGRATED REQUEST-RESPONSE 
SYSTEM AND METHOD GENERATING 
RESPONSES TO REQUEST OBJECTS 
FORMATTED ACCORDING TO VARIOUS 
COMMUNICATION PROTOCOLS 

FIELD OF THE INVENTION 

The present invention generally relates to a method and 
apparatus to accoixq)lish aeation and serving of data objects, 
and more particulady a method and apparatus to accomplish 
creation and serving of data objects in which users and dient 
applications (the recipients of the data objects) have a 
diverse set of properties and capabilities such as ihe use of 
different protocols and data languages in dients and differ- 
ent characteristics of users such as, for example, gender, age, 
interests, and prefexences. 

BACKGROUND OF THE INVENTION 

Open Systems Interconnection (OSI) 
Communications Model 

As will be appreciated by those skilled in die ait, com- 
munication networks and their operations can be described 
according to the Open Systems Interconnection (OSI) 
model This model includes seven layers: an application, 
presentation, session, transport, netwoidc, Unk, and physical 
layer. The OSI model was developed by the International 
C^anizatLon for Standardizaticm (ISO) and is described in 
'The Basics Book of OSI and Network Management" by 
Motorola Codex firom Addison-Wesley Publishing 
Conqjany, Inc, 1993 (First Printing Sq>tembex 1992). 

Eadi lay^ of the OSI model performs a specific data 
communications task, a service to and for the layer tiiat 
precedes it (e.g., the network layer provides a service for the 
transport layer). The process can be likened to placing a 
letter in a series of envelopes before it's sent through the 
postal system. Each succeeding envelope adds another layer 
of processing or overhead information necessary to process 
the transaction. Together, all the envelopes help make sure ^ 
the letter gets to the dgjit address and that the message 
received is Identical to the message sent Once the entire 
package is received at its destination, the envelopes are 
opened one by one until the letter itself emerges exactly as 
written. 

In a data conununication transaction, however, each end 
user is unaware of die envelopes, which perform their 
functions transparently. For exaxnple, an automatic bank 
teller transaction can be tracked through the multilayer OSI 
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processing information is added. When that information is 
removed and processed by the peer layer in the other system, 
it causes various tasks (error correction, flow control, etc.) to 
be performed. 

The ISO has specifically defined all seven layers, which 
are summarized below In the order in which die data actually 
flows as they leave the source: 
Layer 7, the application layer, provides for a user appli- 
cation (such as getting money fiom an automatic bank 
teller machine) to interface with the OSI application 
layer. That OSI qiplication layer has a ccaresponding 
peer layer in the other open system, die bank's host 
computer. 

Layer 6, the presentation layer, makes sure the user 
information (a request for $50 in cash to be debited 
tern your checking account) is in a fomat (Le., syntax 
or sequence of ones and zeros) the destination open 
system can understand. 

Layer 5, the session layer, provides synchronization con- 
trol of data between the open systems (Le., makes sure 
the bit configurations tiiat pass through layer 5 at the 
source are the same as those that pass through layer 5 
at die destination). 

Layer 4, the transport layer, ensures that an end-to-end 
connection has been established between the two open 
systems and is often reliable (i.g., layer 4 at die 
destination '"confirms the request for a connection,'^ so 
to speak, diat it has received from layer 4 at die source). 

Layer 3, the network layer, provides routing and relaying 
of data lhroug;h the network (among other things, at 
layer 3 on the outbound side an "address** gcXs slapped 
on the "envelope" which is dien read by layer 3 at the 
destination). 

Layer 2, the data link layer, includes flow control of data 
as messages pass down throug|i this layer in one open 
system and ttp through die peer layer in die other open 
system. 

Layer 1, die physical interface layer, includes the ways in 
whidx data ccmmunications equipment is connected, 
mechanically and elediically, and the means by which 
the data moves across diose physical connections from 
layer 1 at the source to layer 1 at the destination. 
The particular focus of the following discussion is on 
media access control (MAQ for communication networks 
which is pofonned in die OSI network and data linklayers. 
It will be apprtdsticd by diose skilled in the art that various 
sq)plications and con^nents operating in the odier OSI 



system. One multiple layer system (Open System A) pro- 50 layers may be interchangeably used with die particular MAC 



vides an application layer that is an interface to a person 
attenipting a transaction, while the other multiple layer 
system (Open System B) provides an plication layer diat 
interfaces widi applications software in a bank's host com- 
puter. The corresponding layers in Open Systems A and B 
are called peer layers and communicate through peer pro- 
tocols. These peer protocols provide communication support 
for a user's implication, performing transaction related tasks 
such as debiting an account, dispensing currency, or cred- 
iting an account 

Actual data flow between the two open systons (Open 
System A and Open. System B), however, is firom top to 
bottom in one open system (Open System A, the source), 
across the communications line, and then from bottom to top 
in die odicr open system (Open System B, die destination). 
Each time that user application data passes downward from 
one layff to the next layer in the same system more 
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described below so long as diese qftplications and compo- 
nents adhere to the OSI design stmctures. For exanqile, 
many different OSI physical layer conq>onents (e.g., a 
parallel bus, a serial bus, or a time-slotted channel) can be 
used in conjunction with the same MAC so long as each of 
the OSI physical layer con^nents passes the particular 
information required by OSI design parameters to the OSI 
data link layer. 

Standard Data Communication Network Protocols 

Standard data communication network protocols, sudi as 
that which is described above, offer new abilities and 
corresponding technological prck}lems. Standard network 
protocols suites such as the IVansmission Control Ptt^ocol/ 
Intemet EYotocol suite (TCP/IP) aflow for the easy creation 
of transport-layer protocols. These transport protocols and 
aoconqianying data languages allow for a diverse set of 
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dient applications which communicate using them. This Two- Way Communication and the Drive Towards 

ability to support a diverse client base is a boon to the Peer-To-Peer Mass Communications 

commercial andmainstrcam potential of data communica- ^ communication models emci&ng from usage of data 

Uons networks because diversity is a necessary condition for wimiiuui^-auvii iiiuu^a ^uag^g u vm u^o^jc ui wiw 

a product in the marbitplace.liversity, in soiie cases being 5 ^^"^^^o-^ ^rtworte su^ 

helpfiiL can also be a problem. The main problem with the Ganges in the relationship between data producers and data 

diverse cUent base is that not every dient knows every consumers. It used to be that with die one-to-naany, one-way 

version of cvciy protocol or every dialect of every data niodel of television and radio, content was produced by a 

language. Thus, coordination between a server and these small elite of entertainer-business persons and was con- 

dients can be a difi5cult problem. Electronic mail (email) on sumed by the masses. The two-way nature of data commu- 

the Ihteraet, for example, uses Simple Mail TYanspcrt Pro- nications networks, however, allows for die more intimate 

tocol (SMTP) and adheres to the Request for Comments S22 particq)ation of the consumer. Even to the point of blurring 

(RFCS22) message standard. the distinction between consumer and producer: because of 

Common email clients for the Internet are Udora^ Rlm^ the ability to participate, the old consumer can now be both 

FINE. PRODIGY MaU, and AMERICA ONLINB Mail The a consumer and a produca on networks such as the Internet 

protocols and languages used are all generally the same Relationships on data communications networks are much 

email clients. However, each client has different properties flatter and more egalitarian in die sense diat each participant 

and capabiUties which make the general process of aeating is a peer (both a producer and consumer). One important 

and serving objects via email difficult. For exan^e, email outgrowth of this devated status of the individual on a data 

dients differ in how wide each line of a message may be communications network is that the individual now 

(e-mailmessagcsusedbythePRODIGYe-maUclientare60 20 demands more personalized attention. For example, if a peer 

characters wide, whereas those used by the AMERICA provides another with knowledge about him cr herself (e.g., 

ONUNE e-mail cUent are 49). They also differ in terms of geogr^hic location, gender, age, interests), dicn he cr she 

what extensions they support— some email cUents support expects that responses should take tiiis knowledge into 

dje Multipurpose Internet Mail Extensions (MIME), but account. Apeer can no longer be treated like a demogrM)hic 

most do not Similarly, die World Wide Web (WWW), an 23 average as in the world of television and radio, 
internet-distributed hypermedia (text, ijiiagc, sound, video) 

network, primarily uses I hypertext Transfer Protocol The Technological Problems in Need of Solution 

(HITP) and Hypertext Markup Language (HTML) for its Given tiiesc new data communications networks and their 

communication. technological and social implications, it is evident that new 

The WWW has the same problem as email with regard to 30 systems should provide solutions, for example, to the fol- 

dients. There exist different v ersions of iriTP and different lowing problem: How does one design an integrated system 

dialects of HTML, and most clients do not know all of diem. that uses multiple protocols and data languages and serves 

For exairiple) Netscape Con\munica lions Corporation has data in a way that takes advantage of knowledge about 

put forth its own extensions to HTML for features such as clients and users? 

background images behind text and centered text These 35 npSPRlFnOK OF rfi ATPn abt 

features are not oflBcial industry standards but are becoming DEbUOPnON OF RELATED ART 

just as good in the sense that they ate de facto standards. ability to create and serve objects has been around 

Anotficr problem of the easy i -.it ion ot new transport-layer ^® *® client/server model. Also, the 

protocols is that new trans n-layer i rotocols and data notion of providing services to general users through data 

languages (either standard oj custom) cv^minue materializ- ^ communications networks has been around at least since die 

ing. These protocols and languages either solve new com- VideoTex. However, tiiis technology was 

naunicationsproblenis(such ?s imp.' u! [rfML enhancing liniited and. was more focused on building specialized 

die Ihtemet with hypcrmedi -^). or bt • solve older ones VideoTex teimhials that fit some particular mold required by 

(e.g.. Sun Microsystems* n* v noT / WA extensions to particular servers (see, for C!xan]5)le,U.S. Pat No. 4,805, 119) 

HTML and die JAVA progranmuDg J^^ cuage promise to be ^5 rather than being foaised on making servers be flexible in 

die next best feature for die VS'W \V). handling a variety of client types. This is probably due to die 

_ ^ fact that wodc on VideoTex was done by individuals widi the 

The In^xjrtance of Tntcgnued System television frame of mind-content would be created in a 

With the diversity of data rc 'um u p Mon protocols and central way and then broadcast to the masses. The cultural 

languages, there is a tendcnc or eni jrs to try to build 50 impoartance of peer-to-peer communications was not fully 

a system for each of the rr ^rot • s and languages, recognized at that time. 

radicr than to build a single cm iress all of tiiem. Integrated services platforms have been developed for 

This is because in a certain nse i( asicr to write an telephone networks (see, for example, U.S. Pat No. 5,193, 

individual system wiUi a i\ le iin* domain than an 110) but still only focus on tdcphone calls (essentially a 

integrated system widi a more expan- lomain; one does 55 single protocol as opposed to many). In recent years, a 

not have to expend die effort necess to abstract out the number of online service providers — die IVodigy Service 

common features across a dl crse s . Mowevcr, it is very Company, America Online, CompuServe, and odiers—have 

expensive to maintain many i divi^lr systems and usually developed their own means to create and serve objects in a 

much cheaper to maintain a single i eerated systena. Also, similar vein. Technologically, these companies are not all 

itismuchmorcdifl5culttom^ '^ui'^ i t /re parity and share 60 that different from die oldff Videolbx coir^ianies, Hiey 

data between many individua :n opposed to widiin require users to obtain custom software clients whidi speak 

an integrated system. An add - -1 1 . t of an integrated custom protocols in owier to interact widi tfieir servers, even 

system would be diat, bccar ' c s has already been if dieir software can be used on different personal oon^uters 

taken to abstract out commo. **re various protocols to make tiieir services personal can5)uter-independent (see, 

and languages, it is much 0 t to newer ones, 65 for cxaii^)le, U.S. Pat No. 5347,632). Because of diese 

which will most likely be ab lac. !ar enough to die custom clients and protocols, these services are mutually 

older ones to allow for easy laicgm incon^atible. 
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What is not addressed by services like these is &e FIG. 2C is an exan^le of an unfonnatted DFL object 

growing usage of standard conmmnication protocols and (processed). 

languages (iSe SMTP, HTTP, and HTML), in providing FIG. 2D is an example of a concrete object (client- 
services to standard clients. Ultinjately, fliis usage of pro- specific). 

prietary clients and protocols leads to self-destruction in a 5 piG. 2E is an exanq)lc of an outgoing object, 

marke^lace whidi demands standardization, decentralized pjQ 3^1^ eotanmle of property rules in a configuration 

control, and diversity. Wi& regard to the personalization of database for use in processing objects, 

service, attention has lately been p^^ PIG ^ ^ 1^ of capability rules in a oonfigu- 

customized content to chents such ^ ^^TT^^ ^oT«f nation database for ^in ^oceSng objects, 

commercials (see, for exanmle, U.S. Pat No. 5319,455). ™o - . « u-»r ^ j j- 

Brt<mecanseeli;iritations2^ftep!mosophyof towl^rkto '° KG. 4 is a flow chart of a prrf«c«l request decoding 

that clients are still seen as "viewers" in a one-way com- ^??!^^' - . ^ ^ ' c a a ^ 

munications model, rather than as participants in a two-way FIG. 5 is a diagram cf a prcfened request decoder 

model Also, technologies have been developed to abstract architecture. 

data and present it in dynamic ways based upon user 6 is a diagram showing exan^les of two ways of 

parameters (see, for exanq)le, U.S. Pat Nos. 5,165,030 and 15 processmg and formatting an abstract DFL-embedded DPL 

4,969,093). HowevCT, this effort has not been focused on object. 

protocol-independence and language-independence of this DETADJaD DESCRIFnON 

abstracted data. _ 

Overview 

SUMMARY OF THE I>fVENTION *- ^ i ^ a 

20 liie present uvention solves at least the aforementioned 

This invention is directed to an ^paratus and method fcH* problems. In short, tfie present hivention provides a method 

generating abstract data objects from requests received from and defines an apparatus for aeating and serving custom 

any one of a plurality of communication protocols. In the objects "on-the-fly" (dynamically) for requests coming from 

^jparatus and method, a request is received from any one of users and clients through various protocols and in various 

aphirality of communication prorocols. Additional function- 25 languages. An example of an unplementation of the present 

ality of the apparatus and method determines which of the invention is referred to as dynamic object creation and 

communication protocols was used to transmit the request, serving (DOCS). As shown in FIG. 1, a DOCS method has 

and generates from the request, using results of the four prefetred main phases, eadi of which is performed by 

determining, a corresponding abstract data object, the a particular module in an I5)paratus implementing DOCS: 

abstract data object being independent of the pluraHty of 30 request decoding and object creation U, data processing 12, 

communication protocols. object formatting 13, and object delivery 14. In addition to 

A further apparatus and method in accordance with the modules for these four phases in a DCX^S implementation, 

invention includes, in addition to the elements described there are typically two database modules: a main database 

above, functionality for genern fng from the abstract data module 16 and a configuration database module 15. The 

object a data object which is formatted for transmission 35 main database module 16 provides a read-write memory fox 

according to a communication protocol of an intended storing and serving non-configuration data. The configura- 

redpient of the data object. Uon database module 15 stores configurations for tiie otiicr 

A further apparatus in acco'-'lance with the invention modules, 

mdudes a main database, conf) nition database, and mod- DOCS also uses two different internal languages: a data 

ules coupled to the databases. 1 1 main (iatabase stores data 40 processing language (DPL) and a data formatting language 

to be merged with objects. The c afigiiration database stores pPL). A DFL is a means for specifying conciete, dient- 

oonfigurations for use in decoding requests and formatting independent objects. A DPL is a means for specifying 

objects. A request decoder, coupled to the configuration abstract objects. Usually, abstract objects are defined by 

database, receives an incoming request, decodes tiie request embedding DFL code and code fragnjcnts within die DPL. 

using the configurations in ord< r to identify which protocd 45 The data processor 12 then takes abstract objects defined in 

was used to transmit the reqr an I generates from the a DFL-«mbeddcd DEL and outi»its plain DFL objects for an 

request a corresponding abr Ac^ l-ta object A data object fonnatter. 

Iffocessor, coupled to Uie main tnb.w-, the configuration An object is defined hcrehi as a collection of data. An 

database, and the request decoder, receives the abstract data object may be an image, audio, video, text, or a document 

object from the request decodei m l m rges data from tfie so containing a combination of the above because an object 

main database with the absn. - dai > r^bject An object may contain sub-objects. A request is an object itself, but 

fomiatter, coupled to the configu- abase and tiie data maintains tiie name 'YequesT to distinguish ilsdf from ottier 

proccssor,receivestiiemerged:v ,h ,cf ' ua object firom the objects in DOCS or other iixq>lementations. The torn 

data processor and formats tiie a trict data object induding ••request" also serves as a name for tiie category of incoming 

tiie merged data. An object de rer, coupled to tiie con- 55 objects tiiat would resuU in some sort of processing being 

figuration database and die Ob I Uver r.recdves tiie data pcrfonnedbyaDOCSsystcm,altiiou^a*^uesr doesnot 

object from tiie object formatt .d for ^ats tiie data object neccssaray have to be a request in a human sense. For 

for outgoing transmission ac. c':.ig t. a protocol of an example, tiffough a *Vequest" a client may infonn a DOCS 

hitended recipient of the dat.. = vu system of a particular piece of information (e.g., user X is 5 

BRIEF DESCRimON ^ HE DRAWINGS *° inches tall). Explidtiy this is not a request, but 

FIG. lis a diagram of a prd. J a^ bitecture and flow '^^f^y^^'^^^'':^^ 

diait for implementing tiie ^ese r- tion. tiie information for reference m future '^^^ 

nG.2AisanexampIeofanin equest for object vide tiie dient witii some sort of admowledgment 

FIG. 2B is an example of an ab L-embcddcd DPL 65 0*^^* Request Decoding and Object Creation 

object DFL and DPL stand for * d. iiatting language" A request comes in to a DOCS server 9 from a dient 10 

and "data processing language" I ^ eiy. through one of a plurality of conamunication protocols (e.g.. 
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Simple M ailTVa nsfer Protocol (SMTP), Hypertext Transfer 
ftotocol (HTTP), Request For Comments 822 (RFC822)» or 
Hypertext Markup Language (HTML)). A protocol is any 
means for communication; for exan^le, a process for send- 
ing a message which could include data format. As used 
herein, **protocols" include languages for communication. 

Even though some clients are similar in diat they speak 
die same protocol they may differ in dialect. For exan^le, on 
the World Wide Web, all clients typically use the HTTP 
protocol and HTML (Hypertext Markup Language), though 
different dients use different versions of HnP and speak 
different dialects of HTML. To solve the problem of coor- 
dinating communication across multiple protocols and 
dialects, the request decoder has sub-modules which know 
each desired {^otocol and can recognize properties of vari- 
ous clients (such as preferred data language dialects). As 
used herein^ '^properties" includes properties and c^ahili- 
ties. A capability is a type of property which specifies, for 
example, how a client can format data or perform other 
functions. 

Rule sets are used to decode properties of clients. As in a 
conventional expert system, these rule sets may be encoded 
logical rules and heuristics that tell how to recognize prop- 
erties from protocols and request clues and how to deal with 
particular clients (see FIGS. 3A and 3B). After identifying 
what object was requested, the rc'iuest decoder 11 also 
informs the main database 16 of any information updates 
from the incoming request. To finish the phase^ the request 
decoder creates and passes an ab^tr'>^t DFL-embedded DPL 
skeleton object to the data procc ^ r IZ 

Phase Two: Data Pj ocessing 
The data processor 12 receives the abstract DFL- 



8 

Phase Foun Object Delivery 
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While the request decoder 13 is much like a receiver for 
a server using a DOCS methodology, the object deliverer 14 
is much like a transmitter: Like the request decoder 11, the 
object deliverer 14 has submodules that understand different 
communication protocols, but instead of being designed to 
decode incoming objects, it is designed to format outgoing 
objects for transmissioiL Object formatting and object deliv- 
ery could alternatively be peif ormed in one stage or a single 
process. 

Main Database 

The main database 16 is typically used to store informa- 
tion from incoming requests, record outgoing transactions, 
and serve data to be placed in outgoing objects. 



20 
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Configuration Database 

The configuration database 15 is typically used to store 
configurations for decoding requests and formatting objects. 
The configuration database 15, though logically sq}arate 
from the main database 16, could actually be physically 
stored in the same place as the main database 16 (e.g., in 
relational database tables), although this is not necessary. 

Data Processing Language (DPL) 

A DPL is a language whose function is to organize, 
substitute, and otherwise manipulate data. A DPL may or 
30 may not be a specialized language, thougjh it may be driven 
to be a specialized language by particular needs for data 
manipulation. Usually, a DFL should be robust in function 
and offer basic conditional and control structures (such as 
IFs, loops, and procedure calls) so that these abilities are 



11 and retneves any needed jnfo^ ^lation from the main 

Data Fcnnatting Language (DFL) 



database 16 (such as a classified ad\ 
of a database search) to mer^ \ 
skeleton. When executed, the Vr , ' 
substitutions and other mam]>3jl 
eton object. Prc^erties of user- 
retrieved from the main dat.V ^ 
database 15 can all affect how tli ' 
The result of all of this manipula 



tisement or the results 
'Ji the abstract object 
j ect performs merging 
;s on the abstract skel- 
rlients as well as data 
16 and configuration 
*L object is assenabled, 
is an object d^ned in 



DFL, which is then passed on to c object formatter 13. 
Phase Three: Objr '^rraatting 

The object formatter 13 r c ^ves a merged, but 
unformatted, DFL object from tli :i processor. The object 
formatter 13 then converts the c ent -ndependent DFL data 
object description into a concrt c ^ent-dependent object 
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A DFL is a language whose primary function is to 
organize the presentation of data. A DFL could be imple- 
mented with a markup language (sudi as SCiML or HTML), 
or a sophisticated progranuning language (such as the 
POSTTSCRIPr language). There is no requirement that the 
DPL and DFL be separate languages. It is possible that they 
could be the same language (e.g., the POSTSCRIFr lan- 
gu age could be both a DPL and a DFL because it offers both 
data manipulation abilities and data formatting abilities). 

DESCRIFnON OF A PREFERRED 
EMBODIMENT 



ready for outgoing transport, 
piished by using a set of filters 
of the client) that take a Dl 
particular conaete format such 
a set of configured fonuattin 
concrete fcumats themselves in. 
HTML is a DFL). Theref<ye. 
abstract and powerful eoough to 
the possible DFLs of the concre: 
DFL object is originally embed 
nacnts within a DPL object, sot 
can actually be done by the dat. 
the outputted DFL object can vaj 
the DPL object The object lom^ 
be the only formatting ph 
fonnatting phase before objec. 



onversion is accom- 
ident upon properties 
t and convert it to a 



In a preferred embodiment of die invention disclosed 
herein, a system operates using a programmed computer 
having the UNIX operating system. The exemplary embodi- 
ment uses a SPARCCENTER 2000 server. Other computer 
C822 or HTML using 55 hardware and operating systems c^We cf running on a 
(see FIG. 6). Hie netwodc may be used with some modifications to software 
forms of a DFL (e.g., (e.g., an IBM-Compatihle 80486 personal conoputer having 
-nain DFL should be the MI(310S0FT WINDOWS NT operating system, or a 
s structures in any of Digital Equipment COTporation VAX 11/780 having the 
Its. Also, because die 60 VMS operating system). Although a fffcfeared embodiment 
code and code frag- uses both the P^ and C programming languages, other 
'ie object formatting prograniming languages may be used to implement the 
ssor. This Is because present invention. A preferred embodiment of the invention 
n ding upon inputs to also has program modules for the various phases of a DCX^S 
'base is not meant to 65 method. 

The modules shown in FIG. 1 are an example of an 
in:q)lementation of the phases of a DOCS method. FIGS. 



preferably the final 
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2A-2E illustrate an example of processing a request 
tiiroug^out the modules shown in HG. 1. 

Request Decoding 

The request decoder 11 and object deliverer 14 share 
various protocol modules te comiuunicatioiL There are» for 
example, two protocol modules: one for SMT? electronic 
mail communication and one for I TTTP-based World Wide 
Web communication. These two protocol modules were 
chosen for the exemplary embodiment because these protO: 
cols are both widespread and popular. Other protocol mod- 
ules such as for Sun Microsystems' HOT JAVA language 
can be built using the principles of the present invention. 

The request decoder 11 (see FLG. 1), upon receiving a 
request ^m one of the protocol modules, first discovers 
prq>eilies of the dient and the request with the help of the 
protocol module using sets of rules . The Request Decoder 11 
then routes the request internally to one of several con^ 
nents that handle different kinds of requests (e.g.» requests to 
change database information, requests to perform database 



searches). Final decoding of the j 
abstract DFL-embedded DPL obj ^ 
ponent. FIG. 2A provides an 
request for object 1 received by t 

FIGS. 3A and 3B illustrate an 
and capability rules stored in the 
The request decoder 11 uses thes 
a ]Hotocol which was used to tra^^ 
detccmine other various propert* 
later formatting and data mergir 
properties 17 are correlated usiuj 
ments 19, 20, and 21. By applyir 
to the request, the system can dt 
property 17 such as the protocol \ 
the request Fa: example, if the 
contains "AOLxom," then the s 
request was sent from the AMEV 
shown in FIG. 3B, the systei. 
determine other properties such 
request. This is accomplished 
with properties 23, 24, and 25. 
was transmitted using the Ner 
accommodate tables. 

FIG. 4 is a more detailed flov,' 
U. The request 26 is sent to bof 
an internal request router 30, Ti 
rules 27 from the configuratio 
determine properties of the n- 
These propaties 29, such as a 
requests, are also sent to the rc 
for processing the requests. 

The request router 30 perform" 
oessiiig using request handlers . 
mentation and use of the prescr 
an on-line classified advertisini: 
may include: a anonymous j 
anonymous email; a conun-ir 
commands in the request; a fc 
forms in the request; a seard 
search requests; a profile hand' 
profile; andaregisUration han ' 
on-line registration. The procv, 
38 results in an abstract object 

FIG. 2B provides an exnr 
embedded DPL object 2 rest 
processing of tlie request 1 in X 



nest and creation of the 
is handled by the com- 
Ample of an incoming 
; request decoder 11. 
anq>le of property rules 
1 figuration database 15. 
'Mies in order to identify 
Ait a request and also to 
of a request for use in 
. As shown in FIG. 3A, 
c^dicators 18 with argu- 
:e arguments 19 and 20 
niine the corresponding 
ch was used to transmit 
omline" of the request 
fim determines that the 
, A ONLINE service. As 
uses additional rules to 
'^'uious a^abilities of a 
relating cap^ilities 22 
example, if the request 
1.1 browser, it can 



11. As shown in FIG. 2B, the output of the request decoder 
11 results in various data merging and fonnatting codes in 
the object For exanq)le, the code "[merge USHL-NAME]" 
in the object in FIG. 2B is a code for retrieving a user's name 
5 from the main database 16 and merging it into the location 
of the cQiresponding code in object 2. As another example, 
the code "[include THE.J'OOTER]" in the object in FIG. 
2B is a code for retrieving such a footer from the configu- 
ration database 15 and merging it into the location of the 
corresponding code in object 2. An advantage of these codes 
is that, for exan^Ie, the footer need only be stored in one 
location, die configuration database 15. Therefore, if the 
footer is changed, the new infonnation is merged into iht 
objects without having to change a footer in each individual 
object The footer code typically remains the same, and only 
the footer information changes in the configuration database 
15. 

The various handlers 31-36 (see FIG. 4) are simply one 
exanq)le of an api^cation of the present invention. The 
request handle 38 are application specific and, accordingly, 
the required handlers depend upon such applications used in 
conjunction with the present invention. 

FIG. 5 Is a diagram of a preferred architecture for imple- 
menting the processing of the request decoder 11 described 
in FIG. 4. Based on &e protocol 41 of the data object 
requester 42, corresponding modules 40 in a server request 
decoder 50 are used to process the request for the specific 
protocols. A common functionality module 39 in the server 
request decoder 50 performs additional processing which is 
not unique to any particular protocol. 

Data Processing and Ibxt I^ocessing Language 
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Data processing is handled by an inteqv^ for a spe- 
cialized data processing language called text processing 
language (TFL). Data processing is the execution of a TPL 
program that e:q>resses a particular abstract object. TPL is a 
prefix-operator language that woiks on strings of text and is 
based upon a combination of Scheme, a dialect of LISP and 
Td, a text-based scripting language. TPL is not the only 
possible choice for a data processing language. The reason 
for the choice of TFL is that it can be interpreted and can 
very easily manipulate text-based DFL*s sudi as HTML and 
the POSTSCRIPT language. The DPL docs not necessarily 
have to be interpreted; abstract DPL objects could be passed 
around in a compiled format Nor does the DPL have to be 
a specialized language that operates on tex^based DFL*s. 
The DPL could also be a general purpose programming 
language like USP, the SMALUTALK language, or C++ as 
long as the language can easily manipulate some sort of 
DFL. 

FIG. 6 is a diagram showing exan:q>les of two ways of 
processing and fonnatting an abstract DFL^cmbedded DPL 
object The functionality of both the data processor 12 and 
object formatter 13 is illustrated in FIG. 6. The data pro- 
cessor 12 receives an abstract DFL-embedded DPL object 
43. The data processor then processes codes in the <^ject 43 
using configurations from the configuration database 15 in 
ndler 34 for processing «> order to perform data merging using data fixnn the mam 



50 



n of the request decoder 45 
coperty decoder 28 and 
operty decoder 28 uses 
tabase 15 in order to 
t as described above. 
)Cq1 of the data object 

t router 30 and are used 



'Optional additional pro- 
pending upon an imple- 
. mention. For example, in 
s tern, the request handlers 
iUer 31 for transmitting 
;adler 32 for processing 
andler 33 for processing 
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5 for processing a user's 

6 for processing a user's 
g by the request handlers 
r ddivery 37. 

of an abstract DFL- 
I from the decoding and 
ZA by the request decoder 
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database 16. For example, if the object 43 cannot accom- 
modate tables according to properties 44, the data processor 
12 produces a unformatted DFL object 45 which contains a 
corresponding message regarding the property (e.g. "I am 
sorry, twit your dient doesn't support tables'*). On the other 
hand, if the object 43 supports tables according to properties 
47 , the data processor 12 produces a unformatted DFL object 
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46 which contains the data for the requested table along with "From," '^Subject," etc) are prepended as shown in Table 1. 

the coircsponding codes, Accordin^y, based on properties For HTHP, a standard MIME header is prepended to the 

of the request as determined by the request decoder 11, the HTML document. Configurations for this final preparation 

data processor 12 performs the merging of data or other of objects before transmission are be stored in the configa- 

processing if the properties do not support the data to be 5 ration database 15. 
merged. The actual data and codes shown in FIG. 6 are for 

illustration puiposes only and are singly one example of TABLE 1 

data moging according to the principles of the present ^^^^^"""""""""mr^^^^^^^^^^^"""""" 

invention. Constant: ipiELDS^SBSD) ( 

FIG. 2C provides an example of unformatted DFL object i^ RETintN-PAlH, 

3 resulting from processing of the object 2 by the data received, 

processor 12. Object 2 contains the actual merged data for frSm. 

the table, along with various fonnatting codes. For example, suBJECrr 

the HTML tags *'<B>" and "</B>" indicate that the infor- SBNEER,' 

mation between these tags is to be shown in bold. 13 REFLY-TO» 

ERRORS-TO, 

Data Formatting and Extended HTTML (XETTML) 

Data formatting in the object formatter 12 (see FIG. 1) is commbnx 

handled by a set of filters that convert internal DFL objects conww^cth 

intoconcretedataobjectsready for transport through one of ^ j; 

the communication protocol modules. The formatting rules ' 
used by the filters are stored in the configuration database. 

The present choice for a DFL is a custom, extended version provides an example of an outgoing object 5 

of ITTML called XHTML. Objects are converted fi:om resulting fi-om processing of the object 4 l>y the object 

XHTML to plain HTML for the World Wide Web and to ^ deliverer 14. Object 5 contains tiie "from** and **to*' infor- 

vaiious ASCn formats for RFC822 mail. Plain HTML and mation for transmission. 

RFC822 ASCH are not the only types of formats that can be For certain protocols, it is possible ttiat a redpient of a 

converted to from Xin>4r.., but are so chosen because data object is different than the requester: It is also possible 

electronic mail and the World ^de Web are the currently that the protocol used in a response to a request is different 

available protocol modules. Filters can fairly easily be from &e protocol used in the request itself. For example, one 

written for other formats as well, such as MIME. Again, just client may send a request via the World Wde Web asking 

as with the DFL, XHTML is not the only possible choice for that a particular email message be forwarded to another 

a DFL. XHTML was chosen because it is a text-based known client/user. Usually, however, some sort of acknowl- 

markup language and works well with TPL. There is no edgment is additionally provided to the requester via (he 

requirement that a DFL be text-based, either. However, it same protocol as the request In the case where the recipient 

should be in some format th<it is easily manipulated by an or response protocol are different than the requester or 

accompanying DPL. request protocol, it is not usually immediately discemable 

FIG. 6 illustrates formatting an abstract DFL-embedded what properties or capabilities the rec5)ient will have. 

DPL object by the object iorraattcr 13 in the exan^le ^ Therefore, these properties of fee recquent are typicaUy 

provided above. If the client Joes not support tables in the ^ith^ recalled from memory (in the main database 16), or 

example, the object formatter 13 produces concrete object assumptions are made about them based upon rules and 

48 with the correspondi ng mc ;ige. On the other hand, if the heuristics in the configuration database 15. 

dient supports tables, the o ject formatter 13 produces xm - 

concrete object 49 with the j-aerged data in the requested Database Module 

table. Accordingly, using properties of the data object A preferred embodiment <rf the invention uses a relational 

requester (client) as detcrmi' d by the request decoder 11, database management system (RDBMS) for the main data- 

thc object formatter uses ru* < from the configuration data- base 16. This, again, is not essential. The main database 16 

base in order to process Uic lorraatting codes in the unfor- could be stored in some other type of database, such as an 

matted DFL object in order to produce a concrete object. object database management system (ODMBS), in a set of 

FIG. 2D provides an cxai . le of concrete object 4 result- files in some sort of filesystem, or a combination thereof. No 

ing from processing of the r -ct 3 by the object formatter particular structure is essential. The only requirements are 

13. Object 4 contains the for . \;uted table, assuming that the that the main database module 16 provide a means to store 
client supports tables. the desired data for and atx^t clients and users and that the 

. 55 other modules (the request decoder 11, data processor 12, 

Object l>eUvery jata formatter 13, and object deHvcrer 14) are able to access 

The object deliverer 14 us:^^ *'ie same protocol modules as ^ appropriate ways, 

the request decoder 11 to tr:' port formatted objects back to ' o ^ ■ 

the appropriate client and u ^r. The deliverer performs final Configuration Database Module 

assembling and formatting ' r^nta m order to transmit the 60 A preferred embodiment of tiie invention uses fast, read- 

object. Alternatively, the ob formatter 13 could be con- only lookup tables encoded in data structures in the Pferi 

figured to also perform the f tions of the object deliverer language as its configuration database 15. These lookup 

14. Again, for the object de er 14 > proto col modules do tobies are generated by a conqulex for a configuration 
not have to be limited to SN and HTTP. Before sending definition language (CDL) called resource description lan- 
out an object, appropriate " ^ data" is added to turn the 65 guage (RDL). Using lookup tables is not the only way to 
object into a valid message f he protocoL For example, fix encode the configurations. For example, rule sets may be 
SMTP mail, standard RF^ 2 headers (sudi as *To" con^iled (either by hand or automatically) into pn^ram- 
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xmng language code (such as PerL or assembly language) 
for efficiency or other reasons. Appendix A provides an 
example of segments of RDL showing property and routing 
configurations for email (electronic mail) and W(^d Wide 
Web requests. Appendix B provides an example of segments 
of RDL showing formatting configurations for email and 
World Wide Web requests. Appendix C provides an example 
of segments of Fed which apply compiled property and 
capability rules to analyze requests. 

It is neither essential that the configuration database 15 be 
inq}lemented in Perl data structures (or any other program- 
ming language) nor that these configurations be compiled 
from RDL or any configuration description language. It is 
possible to store die configurations in separate files or even 
in a conventional database system (such as an RDBMS or 
ODBMS). How the configuration database 15 is stored is not 
as important as what is stored and how efficiently items are 
accessed. What is essential about the configuration database 
15 is that it effectively stores the necessary configurations. 
These necessary configurations typically include, as 
described above, rule sets for properties of requests and 
clients, abstract data objects meant for serving, formatting 
rules, delivery preparatioti niles, and any other configura- 
tions for which it is desiV.ibie to have central storage and 
control. 

The invention may be en^bodied in other specific forms 
without departing from the spirit or essential characteristics 
thereof. The present tmbo Uiuents are therefore to be con- 
sidered in all respects as i instrative and not restrictive, the 
scope of the invention bt' indicated be the appended 
claims rather than by \hc foregoing description, and all 
changes which come within the meaning and range of 
equivalency of the daijiis are therefore intended to be 
embraced therein. 

APPf:^a)IX a 

The following segment of RDL shows property and 
routing configurations for enuiil (electronic mail) requests: 



f0 . *mm***m*m**999»* * 

PROPERTY DEFINmOiNS 
Property: (I'O-IIELP) 
Property: 0'0-HELP-EMAIL) 



VICHES-USER-CI 
ATCHBS-USHt-CI CrO, '^euadT); 



Property: (J 0-HELP-BROWSE) NT.VTCHES-USER-a (TO, *TaowO; 
pK^crty: (CONTAINSTORM) MATCHES 
(30DV, 

»=--==rWXm\377]*ECl-^ a):[\\00CW\377]*= ===-"); 

(TCWfflLP, TO-HELP-EMAIL); 
(TCVHBLP, TO-HELP-BROWSaS); 
(TCWffiLP); 
(CONTAINS^ORM); 



ROUTING RULES 

Route: CMP-HELPSERV-EMAJT. 
Rome: CM flELPSERV-BROV 
. Rouic: CN5 ' ilELPSERV-IKl^H 
Rouit;: CMP FORMSERV 



PROITRTY DEFINmONS 

Propcny: 0 AS-FORM) h 

( 

Property': f 'ELCOME) 



- ^ * *«»«•••••*«**•«**«««•*•«***/ 

' nSTLJkffiraOD, -POST): 
.Y__STRING, ""WELCOMB^ 
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The following segnier' f RDL shows property and 
routing configurations for ' -orld Wide Web requests: 



14 

-continued 



Property: (DEFAULT) XRtJH: 
R0XniKORUI£S 

*«••*•»« CM***************************** «•»**««**«« *•«*•/ 

Route: COMPONENT FORMS (HAS-FORM); 
Route: COMPONHNTCOMSERV (WELCOME); 
Route: COMPONENT-UNKNOWN PEFAUU); 
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APPENDIX B 

The following segment of RDL shows formatting con- 
figurations for email requests. 



15 



y« A******************************************************* 

REQUEST PROFEBUBS 

MATCHES-DOMAIN-a 
(PROM, ***tU)LoGai$"); 



Property: (FROM-AOL) 
Property: (FROM-COMPUSEKVE) 
Property: (FROM4>RODK3Y) 



MATCHES-DOMAIN-CI 
(FROMt ***ooa9uservexoin$0; 
MATCHES-DOMAINS 
(FROM, ''"txodigyjcoiiiir*); 
/• •«««*•«»«»•••»•««*»•«««•••*«««•*«•*•«•**«•*«•*•*•*«•*««« 

FORMATIINO RULES 

Fomut-Rule: FMT-AOL (FROM-AOL); 

Fonnat-Rule: FMT-COMPUSERVB (FROMCOMFUSEKVE); 

Format-Rule: FMT-PRODIGY (FROMrPRODKJY); 

Format-Rule: FMT-ASCn (nEFAUUT); 
/* 

FORMAT DEFINmONS 

«**««••*••*•«**«*«***«*«****«•*«***«•«*•*«•«••«••*« 

Fonnat (FMT-ASCIZ) C*fbni»C_ascii", 75, 5); 

Format (FMT-AOL) ("fonnait^^flca", 45, 4); 

Fonnat: (FMT-COMFUSBRVE) ("fiOTnat-flficiT, 75, 5); 

Fonnat: (FMT-PRODIGY) ("fiDnrBt^asdr, 35, 5); 
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The following segment of RDL shows formatting con- 
figurations for World Wide Web requests. 
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PROEERTy DEFINmbNS 

•««•*•*«*«•*#•••«•«**««**•«•««• 

MATCHES-CI (jnTP_USER_AGENT; 

MAICHES^I ( jrnp_usBR^j«aBNT; 

*?JCSAMosaiO; 

MATCHES^ ( jrrn>_usBR_AGan; 

-NCSA Mosaic.*/2\VyO; 
MATCHES-CI ( jmP_USBR_AGENX 
-MaziUaO; 

MATCHES-CI ( jnTP__USEILJVGKNT, 
-MoziUa/lWr'); 

«**«****»»««••«••••«*«•«*«*••*••••••«*«*•«*««••«***••*** 

CAPABILTTY RULES 



Property: (LYNX) 
Property: (MOSAIC) 
Property: (MOSMC-2S) 
Property: (NETSCAPE) 
Property: (NETSCAPB-1.1) 
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Capability-Rule: INUN&IMOS 
C^iUty-Ruk: TABLES 
C^raibility-Rule: INUN&IMdS 
Curability-Rule: EXr-INK3>ALK3N 
CapabiUty-Rule: 1ABI£S 



(MOSAIC); 

(MOSAIC-2J); 

(NETSCAPE); 

(KETSCAFE); 

(NBTSCAFE-1.1); 
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APPENDKC 

The fcdlowing segment of Peri, shows an exan^e of a 
compiled application of property rules. 



sub &]d_piopeities 
65 £ 

local (•fields) = 
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local (^propeHies); 

if (Sficlds {" JrnP_USER_AGENr*} =-/Lyn3iV/oi) 

pusb (©properties, *LYNX^); 
if ($fidds {-JmP_USEICJVGENT'} =-/NCSA Mosaic/oi) 

pusb (®piopeEtjes^ "MOSAIC^; 
if ($6ckb {'•JmP_USE(LjVGENr*} =-/NCSA Mosaic.*V2\.3/oi) 
push (©properties, "MOSArC-2^'); 
($5elds {-JrnT>_USER_AGRNr*} =»-fl^02iilaV/oi) 

push (©properties, ''NETSCAPE'^; 
($ficlds {" jrrn>_USEIL_AGENr'} t>-AMazillaVl\-l/oi) 
push (©properties, "NETSCAPE-l.l'^; 
letum ©properties; 



} 



The following segment of Perl shows an example of a 
compiled application of capability rules. 



sub fincL_capabilities 
{ 

local (©properties) = @_; 

local (©capabilities); 

if (grep ($_jcq "MOSAIC", « prnpcities)) 

{ 

push (©capabilities, "JNLINEJMGS'^; 

} 

if (giep (SLjeq -MOSAIC.2.5", {a>propcities)) 
{ 

push (©capabiKtics, -TABU-S*0; 

} 

if (grep ($_jeq "NEISCAH-", (^ properties)) 
{ 

push (©capabilities, **INLe;E-IMGS**, "EXr.IMO.AIIGN*0; 

if (grep ($_eq "NETSCAPE-M", ©properties)) 
{ 

puih (©capabilities, **TAHL.HS"); 

> 

return ©capabilities; 

} 
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What is claimed is: 

1. An integrated request-rcispoase system, con^aising: 

(a) decoding means fov(*t'r .(iing a received request object 
to determine which c'^ olurality of communicatioD 
protocols was used to u tnsmit the request object; 

(b) parst ng means for pitrsing at least one request from the 
request object based on ifte detennined communication 
protCKol; 

(c) selecting means for selecting a message ten^ate from 
a plurality of message ten:q)lates based on a type of the 55 
at least one parsed re(iiiest; and 

(d) merging means, opcratively coupled to the selecting 
mears , for merging daf-' selected as a function of the at 
le;i5t one parsed requ : with the message template to 
genenite a protocol- i ^endent response. 

2. The integrated reqn esponse system of claim I, 
wherein the decoding mci m nrises means foor detennin- 
ing prof venies of an entity s tctcd from a group consisting 
<rf: a requ ster client and a:, intended recipient of an auto- 
mated resftonse message. 

3. The integrated requc L response system of rlalm 1, 
further comprising means for determining properties of a 



user client, the user client properties being selected from a 
group consisting of: ge<^graphic location, gender, age 
interests, and other demographic information. 

4. Hie integrated request-response system of claim 1, 
j wherein the decoding means ftmfaer conqirises means for 

determimng if the communication ptotocol used to transmit 
the request object is selected from a group consisting of: a 
PRODIGY MAIL protocol and an AMERICA ONLINE 
Mail protocol 

5. The integrated request-response system of daim 1, 
10 further comprising receiving means, operativdy coupled to 

the decoding means, for receiving the request object accord- 
ing to one of the plurality of communication protocols, the 
one protocol being selected from a group consisting of: 
Simple Ma il IVa nsfer Protocol (SMTP), Hypertext Transfer 
13 Protocol (HmP), Request For Comments 822 (RFC822), 
and Hypertext Markup Language (HTML). 

6. For Use in an integrated request-response system, a 
response system for generating responses to various types of 
requests received according to various oomnmnication 

2Q protocols, the response system conqitising: 

(a) selecting means for selecting a message template from 
a plurality of message templates based on a type of a 
request within a request object received by the inte- 
grated request-response system in response to d^- 

25 mining from the request object which of the various 
communication protocols was used to transmit the 
request object; 

(b) merging means, operatively coupled to the selecting 
means, for merging data selected as a function of the 
request with the message template to generate a 
protocol-independent response; and 

(c) formatting means, cperatively coupled to the merging 
means; for formatting an automated response message 
in a format compatible with a client as a function of the 
determined communication protocol and the protocol- 
independent response. 

7. The response system of daim 6, further conqxising 
decoding means^ operativdy coupled to the sdecting means, 
for decoding the request object to detennine properties of 

40 the client, the client being selected from a group consisting 
of: a requester client and an intended recipient of the 
automated response message. 

8. The response system of claim 6, wherein the properties 
are selected from a group consisting of: geographic location, 
gender, age, interests, and other demographic information. 

9. The response system of daim 6, wherein the decoding 
means comprises means for identifying which of the various 
communication protocols was used to transmit the request 
object. 

10. The response system of daim 9, wherein the decoding 
means further comprises means for detennining if the com- 
munication protocol used to transmit the request object is 
sdected from a group consisting of: a ftodigy Mail protocol 
and an America Online Mail protocol 

11. The response system of daim 6, wherein the merging 
means further comprises means for inserting data at particu- 
lar locations within the message ten4>late. 

12. The response system of claim 6, wherein the merging 
means further oon^rises means for performing predeter- 
mined functions in order to generate the data being merged 

^ with the message template. 

13. The response system of daim 12, wherein the merging 
means further comprises means for spediying the predeter- 
mined functions using codes embedded within tiie message 
template. 

65 14. The response system of daim 6, further conqirising: 
(a) means for retrieving rules that correlate properties of 
the client to the various communication protocols; and 
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(b) means for applying the rctzieved lules to the request 
object in Qixler to determine the propehies of the cUeat 

15. The response system of daim 6, further conqxising 
transmitting means, operatively coupled to the formatting 
means, for transmitting the automated response message to 
an intended recipient of the. automated resxK>nse message 
according to one of the various communication protocols, 
the one protocol being selected from a group consisting o^ 
Simple Mail Transfer Protocol (SMTP), Hypertext TYansfer 
Etotocol (HTTP), Request For CwmnMits 822 (RFC822), 
and Hyp^text Markup Language (HTML). 

16. An integrated request-response method, comjirislng: 
(a) decoding a received request object to determine which 

of a plurality of comnivnication protocols was used to 
transmit the request object; 



10 



24. The response method of daim 21, vtliemn decoding 
the request object comprises identifying whidi of the vari- 
ous communication protocols was used to transmit the 
request object 

25. The response method of daim 24, wherdn decoding 
the request object comprises determining if the communi- 
cation protocol used to transmit the request object is selected 
from a group consisting of: a PRODIGY Mail protocol and 
an AMERICA ONLINE Mail protocol. 

26. The response method of daim 21, wherein merging 
data with the message template conqnises inserting the data 
at particular locations within the message tensplate. 

27. The response method of daim 21, wherein morging 
data with the message template conqsises perfonning pre- 



(b) parsing at least one request from the request object 15 determined functions to generate the data being merged with 



based on the determined communication protocol; 

(c) selecting a message template from a plurality of 
message templates based on a type of the at least one 
parsed request; and 

(d) inei ging data selected as a function of the at least one 
parsed request with the message template to generate a 
protocol-independent n ^ponse. 

17. The integrated request response method of daim 16, 
wherein decoding ttic recei ved request object comprises 
decoding properties of an ntity selected from a group 
consisi ini; at a requester cl . it and an intended redolent of 
the autcnr-^ted response me- age. 

18. TIu integrated requi's response method of r^Mm 16, 
further comprising deterniM ng properties of a user dient, 
the user dient properties ircing sdected from a group 
consist! of: geographic location, gender, age, interests, 
and otlier demograptiic information. 

19. The integrated rcques* response method of claim 16, 
wherein decoding tht itrn td request object comprises 

'ion protocol used to transmit 
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the message template. 

28. The response method of daim 27^ wherein merging 
data with the message tenqilate further comprises specifying 
the predetermined functions using codes embedded within 
the message template. 

29. The response method of claim 21, fiirtfaer comprising: 
(a) retrieving rules that correlate properties of the client to 

the various communication protocols; and 
£gpplying the retrieved rules to the request object in order 
to determine the properties of the client 

30. The response method of daim 21, further conqvising 
transmitting the automated response message to an intended 
redpient of the automated response message according to 

30 one of the various communication protocols, the one pro- 
tocol being selected from a group consisting of: Single Mail 
Transfer Protocol (SMTP), Hypertext TYansfer Rrotocol 
(HTTP), Request For Conmients 822 (RFC822), and Hyper- 
text Markup Language (HTML). 

31. An integrated request-response system, con^irisittg: 

(a) receiving means for receiving a request object accord- 
ing to any one of a plurality of communication proto- 
cols; 

(b) decoding means, operatively coiq)led to the recdving 
means, for decoding the request object to determine 
which of the plurality of communication protocols was 
used to transmit the request object; 

(c) parsing means for parsing at least one request from the 
request object based on the determined communication 
protocol; 

(d) sdecting means, operatively coupled to the decoding 
means, for sdecting a message ten^>late from a plural- 
ity of message tenq)lates based on a ^pe of die at least 
one parsed request; 

(e) merging means, operatively coiq>led to tiie sdecting 
means, for merging data selected as a function of the at 
least parsed request with the message template to 
generate a protocol-independent response; 

(f) formatting means, qieratively coupled to the decoding 
means and the merging means, for focmatting an auto- 
mated response message in a format compatible witti a 
client as a function of the detennined communication 
protocol and tiie protocol-independent response; and 

(g) transmitting means, operatively coupled to the for- 
matting means, for transmitting the automated response 
message to an intended recipient of the automated 
response message according to a particular protocol of 
the plurality of communication protocols. 
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